Multiple variable coverage memory for database indexing

ABSTRACT

Technologies related to multiple variable coverage memory for database indexing are generally described. Disclosed methods may be performed to implement high-speed database access to digital service provider customer data as the digital service provider builds an optimized index for a database. Initially, the digital service provider may maintain an appropriate level of service by keeping a relatively slow performing, basic index in a relatively high performance first memory. As the digital service provider builds the optimized index, the digital service provider may maintain the appropriate level of service by gradually shifting from use of the first memory to the use of a relatively lower performance second memory.

CROSS-REFERENCE TO RELATED APPLICATION

This is a U.S. National Stage Application filing under 35 U.S.C. § 371of International Application PCT/US12/35559, entitled “MULTIPLE VARIABLECOVERAGE MEMORY FOR DATABASE INDEXING”, filed on Apr. 27, 2012, which isincorporated by reference herein in its entirety.

BACKGROUND

Unless otherwise indicated herein, the materials described in thissection are not prior art to the claims in this application and are notadmitted to be prior art by inclusion in this section.

Mainstream computer use is evolving from individually managed,stand-alone computing devices to connected devices that access softwareand/or data via a network connection. “Cloud computing” refers to acomputing model in which computing resources may be accessed via anetwork connection, and resources available from the network may bereferred to as “in the cloud”.

Behind a network connection, a “cloud” may often comprise professionallymanaged hardware and software within a data center. A company thatprovides hardware and/or software within a data center, for use by itscustomers, is referred to herein as a “digital service provider”.

One or more customers including, e.g., businesses and/or individuals,may store software and data on a platform including hardware and/orsoftware provided by one or more digital service providers. Examplecustomers may comprise, e.g., businesses engaging in ecommerceactivities. Another example customer may comprise, e.g., “Software as aService” (SaaS) providers. SaaS providers may supply applicationsoftware that can be made available in a cloud to users.

Users that access a customer's software/data “in the cloud” may bereferred to as “cloud clients” or “users”. Therefore, in an examplearrangement, a digital service provider may sell or otherwise providecloud infrastructure to customers, and customers may sell or otherwiseprovide their goods/services to users accessing the cloud.

SUMMARY

The present disclosure generally describes technologies includingdevices, methods, and computer readable media relating to multiplevariable coverage memory for database indexing. Some example methods maycomprise receiving, by a second digital service provider, customer datafrom a first digital service provider. Disclosed methods may beperformed to implement high-speed database access to the customer dataas the second digital service provider builds an optimized, high-speeddatabase index, referred to herein as an optimized index, for thecustomer data. Initially, the second digital service provider maymaintain an appropriate level of service by keeping a basic, relativelyslower performing index, referred to herein as a basic index, in arelatively high performance first memory. As the second digital serviceprovider builds the optimized index, the second digital service providermay maintain the appropriate level of service by gradually shifting fromuse of the basic index in the first memory to the use of the optimizedindex in a relatively lower performance second memory. In someembodiments, response times for retrieving requested customer datarecords in response to received queries may be maintained approximatelyconstant as the second digital service provider builds the optimizedindex and gradually transfers to using the second memory. In someembodiments, methods may include eventually discontinuing use of thebasic index in the first memory.

Some example methods may comprise storing, e.g., by the second digitalservice provider, a database, and furthermore storing the basic index inthe first memory associated with a first performance level; receivingdatabase queries and modifying portions of the basic index for fasterdata retrieval, e.g., using database index optimization tools andtechniques; storing some or all modified portions of the basic index asthe optimized index in the second memory associated with a secondperformance level; and increasing the portions of the basic index storedas the optimized index in the second memory as the basic index ismodified. During the modifying of the basic index, data retrieval may beperformed using the basic and optimized indices, and data retrieval mayincreasingly use the optimized index. The first memory may comprise, forexample, a high-speed cache with a relatively high performance level,while the second memory may comprise, for example, a lower-cost,relatively lower performance memory such as a disk type memory.

In some embodiments, methods may include measuring a time or number oftable lookups involved in retrieving a requested data record using aportion of the basic index; comparing the time or number of tablelookups to a performance requirement; and moving the portion of thebasic index associated with retrieving the requested data record to thesecond memory when the time or number of table lookups meets theperformance requirement. The portions of the optimized index stored inthe second memory may comprise portions of the basic index that areconfigured to locate data records with fewer table lookups or in shortertimes than portions of the basic index stored in the first memory. Insome embodiments, the portions of the optimized index may comprisemodified portions of the basic index which are configured to provide thefaster responses to received queries.

Some example methods may comprise storing, in the first memory, a first(basic) database index; receiving queries and building a second(optimized) database index to provide faster responses to receivedqueries than the basic index; storing the optimized index in the secondmemory; and during the building of the optimized index, responding toreceived queries using the basic index and the optimized index, andincreasingly using the optimized index as the optimized index increasesin size.

Computing devices and computer readable media having instructionsimplementing the various technologies described herein are alsodisclosed. Example computer readable media may comprise non-transitorycomputer readable storage media having computer executable instructionsexecutable by a processor, the instructions that, when executed by theprocessor, cause the processor to carry out any combination of thevarious methods provided herein. Example computing devices may include aserver comprising a processor, a memory, and a database performancebalancing tool configured to carry out the methods described herein.

The foregoing summary is illustrative only and is not intended to be inany way limiting. In addition to the illustrative aspects, embodiments,and features described above, further aspects, embodiments, and featureswill become apparent by reference to the drawings and the followingdetailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other features of the present disclosure will becomemore fully apparent from the following description and appended claims,taken in conjunction with the accompanying drawings. Understanding thatthese drawings depict only several embodiments in accordance with thedisclosure and are, therefore, not to be considered limiting of itsscope, the disclosure will be described with additional specificity anddetail through use of the accompanying drawings, in which:

FIG. 1 is a diagram illustrating an example delivery of customer datafrom a first digital service provider to a second digital serviceprovider;

FIG. 2A is a diagram illustrating a database, first memory, secondmemory, and basic index used by the second digital service provider toservice queries from a cloud client at a time T2;

FIG. 2B is a diagram illustrating the database, first memory, secondmemory, and basic and optimized indices used by the second digitalservice provider to service queries from the cloud client at a time T3;

FIG. 2C is a diagram illustrating the database, first memory, secondmemory, and basic and optimized indices used by the second digitalservice provider to service queries from the cloud client at a time T4;

FIG. 2D is a diagram illustrating the database, first memory, secondmemory, and optimized index used by the second digital service providerto service queries from the cloud client at a time T5;

FIG. 3 is a diagram illustrating a computing device as one example of adigital service provider server;

FIG. 4 is a flow diagram illustrating an example method configured toimplement performance balancing;

FIG. 5 is a flow diagram illustrating an example method configured tostore modified portions of a basic index and/or a second index in asecond memory in connection with performance balancing;

FIG. 6 is a flow diagram illustrating an example method configured toimplement performance balancing during operation of a databaseoptimization tool;

FIG. 7 is a graph illustrating example resource over-provisioning versusindex performance over time;

FIG. 8 is a diagram illustrating multiple index table accesses forretrieving a data record from a database, all arranged in accordancewith at least some embodiments of the present disclosure.

DETAILED DESCRIPTION

In the following detailed description, reference is made to theaccompanying drawings, which form a part thereof. In the drawings,similar symbols typically identify similar components, unless contextdictates otherwise. The illustrative embodiments described in thedetailed description, drawings, and claims are not meant to be limiting.Other embodiments may be utilized, and other changes may be made,without departing from the spirit or scope of the subject matterpresented here. It will be readily understood that the aspects of thepresent disclosure, as generally described herein, and illustrated inthe Figures, may be arranged, substituted, combined, and designed in awide variety of different configurations, all of which are explicitlycontemplated and made part of this disclosure.

The present disclosure is generally drawn, inter alia, to technologiesincluding methods, devices, systems and/or computer readable mediadeployed therein relating to multiple variable coverage memory fordatabase indexing. Disclosed methods may be performed to implementhigh-speed database access to digital service provider customer data asthe digital service provider builds an optimized index for a database.Initially, the digital service provider may maintain an appropriatelevel of service by keeping a relatively slow performing, basic index ina relatively high performance first memory. As the digital serviceprovider builds the optimized index, the digital service provider maymaintain the appropriate level of service by gradually shifting from useof the first memory to the use of a relatively lower performance secondmemory.

FIG. 1 is a diagram illustrating an example delivery of customer datafrom a first digital service provider to a second digital serviceprovider, arranged in accordance with at least some embodiments of thepresent disclosure. FIG. 1 includes a first digital service provider 101configured to interact with a customer 150 and a cloud client 160 attime T1, and a second digital service provider 102 configured tointeract with customer 150 and cloud client 160 at time T2. Firstdigital service provider 101 comprises a database 152 and an index 151at time T1. Second digital service provider 102 comprises database 152and a basic index 153 at time T2.

In FIG. 1, customer 150 may initially, at time T1, maintain an accountwith first digital service provider 101, and customer 150 may forexample interact with first digital service provider 101 via any of avariety of account management interactions, including, e.g., payingfirst digital service provider 101 for use of cloud infrastructure andservices. Cloud client 160 may comprise, e.g. a consumer of customer150's data stored in database 152. Cloud client 160 may be configured toaccess database 152 via queries to first digital service provider 101.In some embodiments, customer 150 and cloud client 160 may be a sameentity, such as a same individual, business, or other organization.

First digital service provider 101 may be configured to use index 151,e.g., an index which may be proprietary to digital service provider 101,to retrieve data from database 152 in response to cloud client 160queries. First digital service provider 101 may be configured to provideresponses to cloud client 160 comprising data records retrieved fromdatabase 152.

For any reason, customer 150 may eventually decide to switch or adddigital service providers, e.g., by opening an account with seconddigital service provider 102, effecting a customer data delivery tomigrate database 152 to second digital service provider 102, andoptionally close customer 150's account with first digital serviceprovider 101. Any of a variety of techniques may be used to carry outthe customer data delivery, e.g., first digital service provider 101 maybe configured to encrypt database 152 and send database 152 via anetwork connection to second digital service provider 102, and seconddigital service provider 102 may be configured to receive and decryptdatabase 152. The customer data delivery may be effective to transfer orcopy database 152 from first digital service provider 101 to seconddigital service provider 102, however, the customer data delivery may beineffective to deliver index 151. For example, index 151 may beproprietary to first digital service provider 101 or otherwiseinoperable by second digital service provider 102.

At time T2, customer 150 may maintain an account with second digitalservice provider 102, wherein customer 150 may for example interact withsecond digital service provider 102 via account management interactions.Cloud client 160 queries to database 152 may be directed to seconddigital service provider 102.

Second digital service provider 102 may be configured to initially usebasic index 153 to retrieve data from database 152 in response to cloudclient 160 queries. Second digital service provider 102 may beconfigured to provide responses to cloud client 160 comprising datarecords retrieved from database 152. Basic index 153 may for examplecomprise any index that can be constructed from database 152 by seconddigital service provider 102 without the benefit of a history of cloudclient 160 queries. Because query data can be used to optimize an indexto make it faster in responding to similar queries, and becauseinitially, second digital service provider 102 may not have access tosignificant query history data for use in index optimization, basicindex 153 may be a relatively low-performing index, in comparison to,e.g., to index 151 and/or to indices that may be built by second digitalservice provider 102 over time, e.g., optimized index 154 as discussedin connection with FIG. 2.

In general, database indices improve data retrieval speed at the cost ofincreased storage space and possibly slower write times as indices areupdated. Digital service providers, such as data centers, need not incurslower write times, because index updating can be performed by adedicated service, however, building an index takes time as well asknowledge of the types of queries being made.

Sometimes a digital service provider 102 may not have meta-informationon data in database 152 being delivered in with migrating customer 150.For example, prior digital service provider 101 may be uncooperativewith customer data delivery or perhaps prior digital service provider101 is cooperative with customer data delivery but considers index 151to be proprietary. In some cases index 151 may not be compatible withsystems provided by second digital service provider 102. For example,current data centers tend to put complex proprietary systems behind eventhe most compatible key-value front end access Application ProgrammingInterfaces (APIs) and focus on compatibility only on cloud client 160facing interfaces. Such proprietary systems are often used because theyallow data centers to use particular hardware configurations that may bepreferred for historical or corporate reasons. In any case, there aretimes where optimized indices are not available at second digitalservice provider 102 for delivered data such as database 152.

Depending upon the circumstances of particular indices, creating andoptimizing indices may not be trivial. Information may be required bothto choose which variables to mix when forming index cardinalities, andin selecting which indices to generate. Even a modest “big data” indexin use in today's data centers may have about 150-200 gigabytes (GB) ofindex space per property, without multiple interactions. With multipleinteractions such an index may fill terabytes or even petabytes ofmemory space. To increase efficiency of indices, support staff who knowsthe data well may engage in manual indexing selections, and/or databaseoptimization tools may be used. The manual index design method does notscale well to data center operations, especially when customer 150 maynot want its data being read by data center staff.

Database optimization tools may comprise software configured to observecloud client 160 queries and build indices based on observed queries.For example, the DB2 Database Management System (DBMS) made by IBMCorporation includes a database optimization tool called “DesignAdvisor”. Design Advisor is configured to auto-index based on Bayesianlearning of submitted queries. The SQL SERVER DBMS made by MICROSOFTCorporation includes a database optimization tool called “Index TuningWizard”. TERADATA and NETEZZA DBMS have similar functions.

In automated index optimization, however, performance of databaseoptimization tools may be related to available query data. For example,database optimization tools may be configured to use a large populationof queries to optimize indices, as well as to reduce index size.Performance of a basic index such as 153 may be poor in comparison withan optimized index such as 154, however second digital service provider102 may nonetheless have no alternative to basic index 153 until indexoptimization occurs. Moreover, second digital service provider 102 maywant to provide a good first impression to customer 150 immediately uponcustomer migration, thus second digital service provider 102 may seek toprovide fast performance during the transition time when faster indicesand/or index optimizations are being built.

FIGS. 2A, 2B, 2C and 2D are diagrams illustrating database 152, a firstmemory 201, a second memory 202, and indices 153, 154 used by seconddigital service provider 102 to service queries from cloud client 160 attimes T2, T3, T4, and T5, respectively, arranged in accordance with atleast some embodiments of the present disclosure. FIGS. 2A, 2B, 2C and2D may be referred to collectively as FIG. 2.

In FIG. 2A, at time T2 corresponding to an initial delivery of database152 to second digital service provider 102, second digital serviceprovider 102 may be configured to store basic index 153 in first memory201. Second digital service provider 102 may be configured to servicequeries from cloud client 160 by using basic index 153 to find requesteddata records in database 152, and to respond to cloud client 160 withresponses including the requested data records.

In some embodiments, second digital service provider 102 may beconfigured to offer optimized database performance from initial launchof database 152 at second digital service provider 102, at time T2, byover-provisioning database 152 and/or basic index 153 with powerfulresources for storage and/or computation. For example, basic index 153may provide a multi-level naive index, and first memory 201 may comprisea fast but expensive memcache-type memory. In some embodiments,memcache-type memory may provide 150-180 microsecond (not millisecond)response times. A ten-level metadata index search in memcache may takeas little as around 1.7 milliseconds (ms). In some embodiments, firstmemory 201 may comprise and elasticache-type memory, currently availablein AMAZON web services.

This disclosure is not limited to any particular type of memory for useas first memory 201, and any memory type whether currently known or asmay be developed in the future may be used in first memory 201, so longas first memory 201 is configured for comparatively faster performancethan second memory 202. For example, in some embodiments, a firstperformance level, “high performance” or “fast” memory for use as firstmemory 201 may include any memory that is configured to operate ataverage query response times which are one half or less of average queryresponse times of second memory 202. Conversely, a second performancelevel, “low performance” or “slow” memory for use as second memory 202may include any memory that configured to operate at average queryresponse times which are twice or more of average query response timesof first memory 201. In some embodiments, a first performance level,“high performance” or “fast” memory for use as first memory 201 mayinclude any memory that is configured to provide substantially the sameor better average query response times with basic index 153, as secondmemory 202 can provide with optimized index 154, and vice versa.

In some embodiments, second memory 202 may comprise a Solid State Drive(SSD) or disk-type memory. Second memory 202 is not limited to anyspecific memory type, and any memory type that provides a secondperformance level which is slower than the first performance levelprovided by first memory 201, as described above, is acceptable for usein embodiments of this disclosure.

It will be appreciated that in some embodiments, first memory 201 may besupplemented or exchanged with any first hardware configured to allowfaster operation of indices, and likewise, second memory 202 may besupplemented or exchanged with any second hardware configured to allowrelatively slower operation of indices. For example, in someembodiments, first memory 201 may be supplemented or exchanged withrelatively powerful computation/processing resources, including forexample dedicated hardware such as one or more Field Programmable GateArrays (FPGAs) or other dedicated hardware configured to access basicindex 153. Second memory 202 may be supplemented or exchanged withrelatively lower power computation/processing resources, including forexample non-dedicated hardware such as standard Central Processing Units(CPUs) for device(s) within second service provider 102 configured toaccessed optimized index 154. Furthermore, this disclosure uses firstmemory 201 and second memory 202 as an example embodiment, however itwill be appreciated that by extension, any number of different memory orother resource performance levels may be used. For example, a thirdmemory, fourth memory, etc. may be included in the second digitalservice provider 102 of FIG. 2.

In FIG. 2B, at time T3 corresponding to an interval after time T2,second digital service provider 102 may be configured to store anoptimized index 154 in second memory 202. Second digital serviceprovider 102 may be configured to service queries from cloud client 160by using indices 153 and 154 to find requested data records in database152, and to respond to cloud client 160 with responses including therequested data records.

In some embodiments, a database optimization tool may modify basic index153 to produce optimized index 154. As portions of basic index 153 areoptimized, those portions can be moved or duplicated to second memory202 and may serve as optimized index 154. In some embodiments, portionsof basic index 153 to move to second memory 202 may be identified bytheir response speed, in terms of time and/or numbers of table lookups,in combination with, or independently of, whether such portions weremodified by the database optimization tool. In other embodiments, thedatabase optimization tool may build optimized index 154 as a secondindex, independent from basic index 153, and second digital serviceprovider 102 may be configured to direct an increasing number of queriesto optimized index 154 as second index increases in size and improves.

In some embodiments, second digital service provider 102 may beconfigured to use optimized index 154 such that average overall responsetimes using optimized index 154 in second memory 202 are substantiallyequivalent to average overall response times using basic index 153 infirst memory 201. For example, in this context, “substantiallyequivalent” response times may include average overall response timesusing basic index 153 may be 50% (or less) faster or slower than averageoverall response times using optimized index 154.

In some embodiments, second digital service provider 102 need notprovide substantially equivalent overall response times with basic index153 and optimized index 154. Response times using optimized index 154which are faster or slower than basic index 153 may be acceptable. Forexample, in some circumstances, basic index 153 in first memory 201 maybe used to prevent unacceptably slow initial performance, and optimizedindex 154 in second memory 202 may be significantly slower than basicindex 153 in first memory 201, but nonetheless acceptable. In somecircumstances, basic index 153 in first memory 201 may be used toprovide slow but acceptable initial performance, and optimized index 154in second memory 202 may be significantly faster than basic index 153 infirst memory 201.

In FIG. 2C, at time T4 corresponding to an interval after time T3,second digital service provider 102 may be configured to storeadditional portions of basic index 153, as optimized index 154 in secondmemory 202. Second digital service provider 102 may be configured toservice queries from cloud client 160 by using indices 153 and 154 tofind requested data records in database 152, and to respond to cloudclient 160 with responses including the requested data records.

In some embodiments, second digital service provider 102 may beconfigured to gradually reduce resources of first memory 201 providedfor database 152 and/or basic index 153, e.g., reducing resources offirst memory 201 used by basic index 153 at each of times T3, T4, andT5. Second digital service provider 102 may be configured to buildoptimized index 154 using progressive query data, and to store optimizedindex 154 in second memory 202. Second memory 202 may comprise a memorywhich can be provided at lower cost, albeit with lower performance, thanfirst memory 201. Storing optimized index 154 in second memory 202 neednot affect overall performance, because performance gains provided byoptimized index 154 may offset performance loss associated withtransitioning to second memory 202. Second digital service provider 102may be configured to gradually increase resources of second memory 202provided for database 152 and/or optimized index 154, e.g., at times T3,T4, and T5, as query data is gathered that allows building optimizedindex 154. In other words, second digital service provider 102 maysystematically reduce resources of first memory 201 used in connectionwith database 152, e.g. by reducing resources of first memory 201 usedat each of multiple successive time intervals. Second digital serviceprovider 102 may systematically increase resources of second memory 202used in connection with database 152, e.g. by increasing resources offirst memory 201 used at each of multiple successive time intervals.Second digital service provider 102 may thereby achieve a long-termtransition from use of first memory 201 to use of second memory 202, inconnection with database 152.

In FIG. 2D, at time T5 corresponding to an interval after time T4,second digital service provider 102 may be configured to store completedoptimized index 154 in second memory 202. Second digital serviceprovider 102 may be configured to service queries from cloud client 160by using optimized index 154 to find requested data records in database152, and to respond to cloud client 160 with responses including therequested data records. Second digital service provider 102 mayoptionally be configured to discontinue basic index 153, such as bydeleting or otherwise discarding basic index 153, or evicting basicindex 153 from first memory 201. In some embodiments, second digitalservice provider 102 may be configured to manage transition to use ofoptimized index 154 so as to maintain constant performance from time T2to fully optimized steady-state operation at time T5, with minimalexpense for over-provisioning.

In FIG. 2, second digital service provider 102 may be configured totemporarily accelerate access to database 152 with supplemental highperformance relatively expensive resources such as provided in firstmemory 201 while building efficient database optimized index 154 so thatperformance requirements of second digital service provider 102 and/orcustomer 150 can be met while optimized index 154 is being constructed.As optimized index 154 is constructed, queries from cloud customer 160may be increasingly served by the relatively cheaper resources of secondmemory 202 which use optimized index 154. Second digital serviceprovider 102 may be configured to continuously adjust acceleration ofaccess to database 152 via first memory 201, to provide desired databaseaccess service speeds from initial delivery at time T2.

In some embodiments, basic index 153 can be configured to service anyquery. However, use of basic index 153 may entail as many as 8-10different index table lookups, or more, through basic index 153 assearches are performed for data records in database 152. Such a highnumber of index table lookups in basic index 153 may be consideredunacceptable in many circumstances. For example, each check of a diskbased query may take about ten milliseconds, resulting in overall queryservice times of 100-200 ms, for 8-10 index checks plus final diskaccess for a data record, plus communication and algorithm time. Thiscompares with an expectation from an efficient index, such as optimizedindex 154, of around 3-50 ms for 1-2 index checks plus final diskaccess, communication and algorithm time.

To avoid delays associated with additional index table lookups in basicindex 153, while minimizing operational costs, second digital serviceprovider 102 may be configured to combine use of basic index 153 withuse of initially small, but gradually increasing optimized index 154,while basic index 153 is run in high performance first memory 201.

In some embodiments, optimized index 154 may increase in size, and lowerquality basic index 153 may decrease in size, e.g., by transferringcoverage of data areas within database 152 from basic index 153 tooptimized index 154. Thus at times T2, T3, T4, and T5, index coveragefor database 152 goes from being dominated by basic index 153 at T2, tobeing dominated by optimized index 154 at T5, as query usage data iscollected to optimize portions of basic index 153. Optimized index 154may be configured to utilize fewer different index tables to returnfinal positions of requested data records in database 152 than basicindex 153, so optimized index 154 can be placed on a slower storagemedia associated with second memory 202, such as SSD or spinning disk,without necessarily reducing speed of access to database 152. In someembodiments, second digital service provider 102 may be configured tomaintain roughly constant database performance over time as seconddigital service provider 102 transitions from basic index 153 inexpensive first memory 201 to optimized index 154 in cheaper secondmemory 202.

In some embodiments, second digital service provider 102 may beconfigured to manage the use of basic index 153 in first memory 201 andoptimized index 154 in second memory 202 according to relative costs offirst memory 201 versus second memory 202. To calculate cost, seconddigital service provider 102 may be configured to determine a size ofbasic index 153, and to multiply the index size by the cost per unit ofmemory per unit of time, e.g., cost per GB per hour. The resulting costfigure may be applied in a function to determine, for example,performance requirements for optimized index 154. A high cost of memory201 may justify lowering performance requirements for optimized index154, so that use of optimized index 154 in lower cost memory 202increases more rapidly. Conversely, a low cost of memory 201 may justifyincreasing performance requirements for optimized index 154, so that useof optimized index 154 in lower cost memory 202 increases more slowly.

In an example memory cost calculation, second digital service provider102 may for example determine a size of basic index 153 to be around 170GB. This is a reasonably expected index size for databases containingabout a billion data records, although index size can vary widely withnumber of variables and richness of included data. Currently the costper GB for first memory 201 of elasticache-type memory is around $0.03per GB per hour. Thus cost for placing basic index 153, for the billionrecord database, in high performance first memory 201 can be estimatedat roughly $5.00/hr or $100/day. Meanwhile, currently typical indexoptimizing techniques can take anywhere from a day to a month to createoptimized index 154, depending on query frequency and query homogeneity.So costs associated with using first memory 201 for basic index 153 maybe roughly $100 to $3,000 for the billion record database. Such costscan be adjusted by adjusting performance requirements as describedabove.

FIG. 3 is a block diagram of a computing device 300 as one example of adigital service provider server, arranged in accordance with at leastsome embodiments of the present disclosure. In a very basicconfiguration 301, computing device 300 may include one or moreprocessors 310 and system memory 320. A memory bus 330 may be used forcommunicating between the processor 310 and the system memory 320.

Depending on the desired configuration, processor 310 may be of any typeincluding but not limited to a microprocessor (μP), a microcontroller(μC), a digital signal processor (DSP), or any combination thereof.Processor 310 may include one or more levels of caching, such as a levelone cache 311 and a level two cache which may for example implementfirst memory 201, a processor core 313, and registers 314. The processorcore 313 may include an arithmetic logic unit (ALU), a floating pointunit (FPU), a digital signal processing core (DSP Core), or anycombination thereof. A memory controller 315 may also be used with theprocessor 310, or in some implementations the memory controller 315 maybe an internal part of the processor 310.

Depending on the desired configuration, the system memory 320 may be ofany type including but not limited to volatile memory (such as RAM),non-volatile memory (such as ROM, flash memory, etc.), or anycombination thereof. System memory 320 typically includes an operatingsystem 321, one or more applications 322, and program data 325. In someembodiments, operating system 321 may comprise a virtual machine that ismanaged by a Virtual Machine Manager (VMM). Applications 323-324 mayinclude, for example, performance balancing tool module(s) 323 anddatabase optimization tool module(s) 324. Program data 326-327 mayinclude data 326 and data 327 that may be used by applications 323-324,respectively.

Computing device 300 may have additional features or functionality, andadditional interfaces to facilitate communications between the basicconfiguration 301 and any required devices and interfaces. For example,a bus/interface controller 340 may be used to facilitate communicationsbetween the basic configuration 301 and one or more data storage devices350 via a storage interface bus 341. The data storage devices 350 may beremovable storage devices 351, non-removable storage devices which mayfor example implement second memory 202, or a combination thereof.Examples of removable storage and non-removable storage devices includemagnetic disk devices such as flexible disk drives and hard-disk drives(HDD), optical disk drives such as compact disk (CD) drives or digitalversatile disk (DVD) drives, solid state drives (SSD), and tape drives,to name a few. Example computer storage media may include volatile andnonvolatile, removable and non-removable media implemented in any methodor technology for storage of information, such as computer readableinstructions, data structures, program modules, or other data.

Level 1 cache 311, first memory 201, system memory 320, removablestorage 351, and second memory 202 are all examples of computer storagemedia. Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CD-ROM, digitalversatile disks (DVD) or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium that may be used to store the desired informationand that may be accessed by computing device 300. Any such computerstorage media may be part of device 300.

Computing device 300 may also include an interface bus 342 forfacilitating communication from various interface devices (e.g., outputinterfaces, peripheral interfaces, and communication interfaces) to thebasic configuration 301 via the bus/interface controller 340. Exampleoutput devices 360 include a graphics processing unit 361 and an audioprocessing unit 362, which may be configured to communicate to variousexternal devices such as a display or speakers via one or more A/V ports363. Example peripheral interfaces 370 may include a serial interfacecontroller 371 or a parallel interface controller 372, which may beconfigured to communicate through either wired or wireless connectionswith external devices such as input devices (e.g., keyboard, mouse, pen,voice input device, touch input device, etc.) or other peripheraldevices (e.g., printer, scanner, etc.) via one or more I/O ports 373.Other conventional I/O devices may be connected as well such as a mouse,keyboard, and so forth. An example communications device 380 includes anetwork controller 381, which may be arranged to facilitatecommunications with one or more other computing devices 390 over anetwork communication via one or more communication ports 382.

The computer storage media may be one example of a communication media.Communication media may typically be embodied by computer readableinstructions, data structures, program modules, or other data in amodulated data signal, such as a carrier wave or other transportmechanism, and include any information delivery media. A “modulated datasignal” may be a signal that has one or more of its characteristics setor changed in such a manner as to encode information in the signal. Byway of example, and not limitation, communication media may includewired media such as a wired network or direct-wired connection, andwireless media such as acoustic, radio frequency (RF), infrared (IR),and other wireless media.

Computing device 300 may be implemented as a server in a data centerprovided by second digital service provider 102. Computing device 300may also be implemented as any server that takes over a database in anynumber of other contexts. Computing device 300 may also be implementedas a personal or business use computer including both laptop computerand non-laptop computer configurations.

FIG. 4 is a flow diagram illustrating an example method configured toimplement performance balancing, arranged in accordance with at leastsome embodiments of the present disclosure. The example flow diagram mayinclude one or more operations/modules as illustrated by blocks 323,400-402 and 410-413, which represent operations as may be performed in amethod, functional modules in a computing device 300, and/orinstructions as may be recorded on a computer readable medium 450. Theillustrated blocks 323, 400-402 and 410-413 may be arranged to providefunctional operations of performance balancing tool 323, including oneor more of “Query Handling” at block 400 and “Index Management” at block410. Block 400 may comprise “Receive Queries” at block 401 and “RetrieveRequested Data Records Using Indices in First and Second Memories” atblock 402. Block 410 may comprise “Store Index in First Memory” at block411, “Activate Database Optimization Tool” at block 412, and/or “StorePortions of Index/Second Index in Second Memory” at block 413.

In FIG. 4, blocks 323, 400-402 and 410-413 are illustrated as includingblocks being performed sequentially, e.g., with block 400 first andblock 410 last. It will be appreciated however that these blocks may bere-arranged as convenient to suit particular embodiments and that theseblocks or portions thereof may be performed concurrently in someembodiments. It will also be appreciated that in some examples variousblocks may be eliminated, divided into additional blocks, and/orcombined with other blocks.

FIG. 4 illustrates an example method by which computing device 300operated by second service provider 102 may gradually create optimizedindex 154, while shifting from using basic index 153 in first memory 201to optimized index 154 in second memory 202. In some embodiments,methods according to FIG. 4 may include, inter alia, storing, by block411, in first memory 201 associated with a first performance level,basic index 153 configured to locate data records in database 152;receiving, by block 401, queries comprising requests for one or more ofthe data records in database 152; modifying, by database optimizationtool 324 activated by block 412, basic index 153 using query datacorresponding to received queries to configure basic index 153 toprovide faster responses to received queries; storing, by block 413, oneor more portions of basic index 153 as optimized index 154 in secondmemory 202 associated with a second performance level, wherein thesecond performance level is lower than the first performance level;increasing, by block 413, the portions of basic index 153 stored asoptimized index 154 in second memory 202 as basic index 153 is modified;and retrieving, by block 402, requested data records in response toreceived queries, wherein during the modifying of basic index 153, theretrieving is performed using portions of basic index 153, 154 in firstand second memories 201 and 202, respectively, and wherein theretrieving increasingly uses the portions of optimized index 154 insecond memory 202 as the portions of optimized index 154 in secondmemory 202 are increased.

In some embodiments, methods according to FIG. 4 may include, interalia, storing, by block 411, in first memory 201 associated with a firstperformance level, basic index 153 configured to locate data records indatabase 152; receiving, by block 401, queries comprising requests forone or more of the data records in database 152; building, by databaseoptimization tool 324 activated by block 412, a second, optimized index154 configured to locate the data records in database 152, whereinbuilding optimized index 154 comprises using query data corresponding toreceived queries to configure optimized index 154 to provide fasterresponses to received queries than basic index 153, and whereinoptimized index 154 increases in size pursuant to the building; storing,by block 413, optimized index 154 in second memory 202 associated with asecond performance level, wherein the second performance level is lowerthan the first performance level; and retrieving, by block 402,requested data records in response to received queries, wherein duringthe building of optimized index 154, the retrieving is performed usingbasic index 153 and optimized index 154, and wherein the retrievingincreasingly uses optimized index 154 as optimized index 154 increasesin size.

In a “Performance Balancing Tool” block 323, computing device 300 may beconfigured to perform all operations pursuant to servicing queriesdirected to database 152 while balancing performance of database 152 asoptimized index 154 is created. Block 323 may include blocks 400 and410.

In a “Query Handling” block 400, computing device 300 may be configuredto receive and respond to queries from cloud customers, while providingquery data for use in index optimization. Block 400 may include blocks401 and 402.

In a “Receive Queries” block 401, computing device 300 may be configuredto receive queries from cloud customers. Received queries may take avariety of forms. In some embodiments, received queries may be calls todatabase 152 received via a network connecting second service provider102 with cloud client 160. In some embodiments, database 152 may supporta website, e.g., an ecommerce website, and queries may be generated aspart of a user session on the website. Services included in the websitemay generate calls to database 152. In such embodiments, block 401 maycomprise receiving queries generated within computer 300 or anothercomputer provided by second service provider 102. Block 401 may befollowed by block 402.

In a “Retrieve Requested Data Records Using Indices in First and SecondMemories” block 402, computing device 300 may be configured to use basicindex 153 and optimized index 154, in first memory 201 and second memory202, respectively, to retrieve data records from database 152 asrequested in queries received in block 401.

In some embodiments, block 410 may be configured to maintain an indexrouting table that establishes which queries to direct to basic index153, and which queries to direct to optimized index 154, as describedbelow. Block 402 may be configured to determine a query type of areceived query, and to refer to the index routing table to determine anappropriate index to use. In some embodiments, query type may correspondto portions of database 152 covered by indices 153 and 154. Block 402may be configured to use the appropriate index to retrieve requesteddata records from database 152, and to respond, e.g., to cloud customer160 or to another requesting process, by providing retrieved datarecords. As optimized index 154 increases in size, the index routingtable may be updated to direct more queries to optimized index 154.

In some embodiments, block 402 may be configured to direct some portionof all queries, regardless of query type, to basic index 153, and someportion of all queries, regardless of query type, to optimized index154. As optimized index 154 increases in size, block 402 may beconfigured to direct a larger proportion of all queries to optimizedindex 154.

In some embodiments, block 400 may be configured to measure queryresponse times and/or numbers of index table lookups (also referred toherein as index calls) between receiving a query in block 401 andretrieving requested data record(s) in block 402. Block 400 mayfurthermore be configured to correlate measured query responsetimes/number of index calls with query type. In particular, block 400may correlate measured query response times/number of index calls withwhether optimized index 154 or basic index 153 was used to service aquery. Query handling performance data may be provided for use by indexmanagement 410 as described below. Block 400 may be followed by block410.

In an “Index Management” block 410 computing device 300 may beconfigured to manage indices 153, 154 stored in first and secondmemories 201, 202, respectively. Block 410 may include blocks 411-413.

In a “Store Index in First Memory” block 411, upon initially receivingdatabase 152, computing device 300 may be configured to store basicindex 153 in first memory 201. Block 411 may be followed by block 412.

In an “Activate Database Optimization Tool” block 412, computing device300 may be configured to activate database optimization tool 324 tobegin optimizing basic index 153 and/or creating a second index fromscratch, using received queries to optimize query response times. Insome embodiments, block 412 may be configured to adapt block 402 toprovide query data to database optimization tool 324. Block 412 may befollowed by block 413.

In a “Store Portions of Index/Second Index in Second Memory” block 413,in some embodiments, computing device 300 may be configured to storeportions of basic index 153 in second memory 202, as optimized index154. In some embodiments, block 413 may be configured to determine whichportions of basic index 153 are optimized, e.g., by operation ofdatabase optimization tool 324. Block 413 may be configured tocommunicate with database optimization tool 324 to ascertain whichportions of basic index 153 have been optimized. Block 413 may beconfigured to store the optimized portions of basic index 153 asoptimized index 154 in second memory 202, so that optimized index 154comprises modified portions of basic index 153 which are configured toprovide faster responses to received queries.

In some embodiments, block 413 may be configured to determine whichportions of basic index 153 are configured to locate data records withfewer index calls or in shorter times than remaining portions of basicindex 153, and to move those portions to optimized index 154 in secondmemory 202. For example, in some embodiments, block 413 may beconfigured to store portions of basic index 153 as optimized index 154in second memory 202 when such portions of basic index 153 areconfigured to locate data records with 5 or fewer index calls, or whensuch portions otherwise meet a performance requirement comprising anallowable number of index calls. In some embodiments, block 413 may beconfigured to store portions of basic index 153 as optimized index 154in second memory 202 when such portions of basic index 153 areconfigured to locate data records in a time of 50 milliseconds orshorter, or when such portions otherwise meet a performance requirementcomprising an allowable retrieval time.

In some embodiments of block 413, computing device 300 may be configuredto store optimized index 154 in second memory 202, as an independentsecond index, rather than building optimized index 154 from portions ofbasic index 153. Second, optimized index 154 may be configured to locatedata records with fewer index calls and/or in shorter times than first,basic index 153. For example, optimized index 154 may be configured tolocate data records with 5 or fewer table lookups, or otherwise in anumber of table lookups that meets a table lookup performancerequirement. Second index may be configured to locate data records indatabase 152 in a time of 50 milliseconds or shorter, or otherwise in atime that meets a speed performance requirement. Further aspects ofblock 413 are described below in connection with FIG. 5.

FIG. 5 is a flow diagram illustrating an example method configured tostore portions of an index and/or a second index in a second memory inconnection with performance balancing, arranged in accordance with atleast some embodiments of the present disclosure. The example flowdiagram may include one or more operations/modules as illustrated byblocks 413 and 501-504, which represent operations as may be performedin a method, functional modules in a computing device 300, and/orinstructions as may be recorded on a computer readable medium 450, asillustrated in FIG. 4. The illustrated blocks 413 and 501-504 may bearranged to provide functional operations of storing portions of anindex and/or a second index in second memory 413, including one or moreof “Gather Query Handling Performance Data” at block 501, “ComparePerformance Data to Performance Requirement” at block 502, “PerformanceData Meets or Exceeds Performance Requirement: Move Portion of Index toSecond Memory/Direct Additional Queries to Second Memory” at block 503,and “Performance Data Does Not Meet Performance Requirement: MovePortion of Index to First Memory/Direct Additional Queries to FirstMemory” at block 503.

In FIG. 5, blocks 413 and 501-504 are illustrated as including blocksbeing performed sequentially, e.g., with block 501 first and block 503or 504 last. It will be appreciated however that these blocks may bere-arranged as convenient to suit particular embodiments and that theseblocks or portions thereof may be performed concurrently in someembodiments. It will also be appreciated that in some examples variousblocks may be eliminated, divided into additional blocks, and/orcombined with other blocks.

FIG. 5 illustrates an example method by which computing device 300 maybe configured to implement storing portions of basic index 153 and/or asecond index in second memory 202 according to block 413 in FIG. 4.

In a “Gather Query Handling Performance Data” block 501, computingdevice 300 may be configured to gather query handling performance data,e.g., which data may be provided by block 400 as described above. Queryhandling performance data may comprise query response times, as well ascorrelations between query response times and usage of optimized index154 or basic index 153. In some embodiments, query handling performancedata may furthermore comprise information identifying particularportion(s) of an index used in responding to a query. Block 501 may befollowed by block 502.

In a “Compare Performance Data to Performance Requirement” block 502,computing device 300 may be configured to compare data gathered in block501 with performance requirements. In some embodiments, a single queryresponse time performance requirement, e.g., 50 ms or less, may beestablished for all queries, regardless of index. In some embodiments,different performance requirements may be established for differentindices, and block 502 may be configured to compare data gathered inblock 501 with performance requirement(s) for the index used to servicea corresponding query. Block 502 may be followed by block 503 or 504.

In a “Performance Data Meets or Exceeds Performance Requirement: MovePortion of Index to Second Memory/Direct Additional Queries to SecondMemory” block 503, in some embodiments, computing device 300 may beconfigured to move a portion of basic index 153 to second memory 202when determined in block 502 that query handling performance data meetsor exceeds a performance requirement. For example, when query handlingperformance data indicates that a query was serviced in 30 ms and aperformance requirement for the query was 50 ms or less, the queryhandling performance data exceeds the performance requirement by beingfaster than the performance requirement, and a portion of basic index153 corresponding to the query may be moved to second memory 202. Insome embodiments, computing device 300 may be configured to directadditional queries to second memory 202 when determined in block 502that query handling performance data meets or exceeds a performancerequirement. For example, when query handling performance data indicatesthat average overall query response times for optimized index 154 meetor exceed a performance requirement, block 503 may be configured todirect additional queries to optimized index 154 in second memory 202.For example, if average overall query response times for optimized index154 are 49 ms and a performance requirement for average overall queryresponse times was 50 ms or less, the query handling performance dataexceeds the performance requirement by being faster than the performancerequirement, and block 503 may be configured to direct additionalqueries to optimized index 154 in second memory 202.

In a “Performance Data Does Not Meet Performance Requirement: MovePortion of Index to First Memory/Direct Additional Queries to FirstMemory” block 504, in some embodiments, computing device 300 may beconfigured to move a portion of optimized index 154 back to first memory201 when determined in block 502 that query handling performance datadoes not meet a performance requirement. For example, when queryhandling performance data indicates that a query was serviced in 60 msand a performance requirement for the query was 50 ms or less, the queryhandling performance data does not meet the performance requirement bybeing slower than the performance requirement, and a portion ofoptimized index 154 corresponding to the query may be moved to secondmemory 202. In some embodiments, computing device 300 may be configuredto direct additional queries to first memory 201 when determined inblock 502 that query handling performance data does not meet aperformance requirement. For example, when query handling performancedata indicates that average overall query response times for optimizedindex 154 does not meet a performance requirement, block 503 may beconfigured to direct additional queries to basic index 153 in firstmemory 201. For example, if average overall query response times foroptimized index 154 are 51 ms and a performance requirement for averageoverall query response times was 50 ms or less, the query handlingperformance data does not meet the performance requirement by beingslower than the performance requirement, and block 503 may be configuredto direct additional queries to basic index 153 in first memory 201.

Blocks 501-504 may be performed at any interval. In some embodiments,blocks 501-504 may be performed according to a time interval, e.g.,every 10 seconds. In some embodiments, blocks 501-504 may be performedaccording to a query interval, e.g., every 100,000 queries. In someembodiments, blocks 501-504 may be performed each time optimized index154 is modified by database optimization tool 324.

In some embodiments, block 413 may be configured to maintain the indexrouting table that establishes which queries to direct to basic index153, and which queries to direct to optimized index 154, for use byquery handling block 400 as described above. For example, block 413 maybe configured to update the index routing table each time a portion ofbasic index 153 is moved to optimized index 154. In some embodiments,the index routing table may correlate query types with index 153 or 154.In some embodiments, the index routing table may correlate queryportions of database 152 with index 153 or 154.

FIG. 6 is a flow diagram illustrating an example method configured toimplement performance balancing during operation of databaseoptimization tool 324, arranged in accordance with at least someembodiments of the present disclosure. The example flow diagram mayinclude one or more operations/modules as illustrated by blocks 323,401, 402, 413, and 324 which represent operations as may be performed ina method, functional modules in a computing device 300, and/orinstructions as may be recorded on a computer readable medium 450, asillustrated in FIG. 4. The illustrated blocks 323, 401, 402, 413, and324 may be arranged to provide functional operations of performancebalancing according to block 323, during operation of databaseoptimization tool 324. Block 323 may include one or more of “ReceiveQueries” at block 401, “Retrieve Requested Data Records Using Indices inFirst and Second Memories” at block 402, and/or “Store Portions ofIndex/Second Index in Second Memory” at block 413.

In FIG. 6, blocks 401, 402, and 413 are illustrated as including blocksbeing performed sequentially, e.g., with block 401 first and block 413last. It will be appreciated however that these blocks may bere-arranged as convenient to suit particular embodiments and that theseblocks or portions thereof may be performed concurrently in someembodiments. It will also be appreciated that in some examples variousblocks may be eliminated, divided into additional blocks, and/orcombined with other blocks.

FIG. 6 illustrates an example method by which computing device 300 maybe configured to implement performance balancing after basic index 153is stored in first memory 201, according to block 411, and afterdatabase optimization tool 324 is activated, according to block 412. Insome embodiments, during continuous operation of database optimizationtool 324, blocks 401, 402, and 413 may be replayed in a substantiallycontinuous loop, e.g., block 413 may evaluate performance and determinewhether to move portions of basic index 153, or change query routing,after each query is serviced. In some embodiments, during continuousoperation of database optimization tool 324, blocks 401 and 402 mayoperate to service all incoming queries, and block 413 may operate atintervals as described above. Each of the blocks illustrated in FIG. 6is described above.

FIG. 7 is a graph illustrating example resource over-provisioning versusindex performance over time, arranged in accordance with at least someembodiments of the present disclosure. FIG. 7 illustrates initially highover-provisioning with low index performance. Over time, indexperformance improves with the use of optimized index 154, and soover-provisioning may be reduced.

The index performance curve in FIG. 7 may also be viewed as a querysamples curve, because index performance improves with number of querysamples to use for index optimization. As second digital serviceprovider 102 builds up a history of query samples, second digitalservice provider 102 may be configured to decrease resourceover-provisioning to provide a substantially constant performance level.The over-provisioning may be implemented using split-media index storageapproach as described herein, so that performance of a relatively lowquality index using high performance memory resources substantiallymatches performance of a relatively high quality index using lowerperformance memory a high quality, lower cost index as the higherquality index is under construction, thereby normalizing performanceover time as the transition in this FIG. 7 takes place.

FIG. 8 is a diagram illustrating multiple index table lookups/indexcalls for retrieving a data record from a database, arranged inaccordance with at least some embodiments of the present disclosure.FIG. 8 illustrates an example key-value store with multiple indextables. Third tables 803 may comprise actual locations of one or morekey-values; however multiple levels of metadata trees above third tables803, in the form of second tables 803 and first table 801, may beaccessed in order to correctly access third tables 803. Loweroptimization indexes typically manifest as larger metadata tables withmore layers of them in the tree, resulting in more index reads to findthe eventual address of target data records in a database. For example,it is common for a completely naive index to be 8-10 tables deep, whilea well designed index may be organized in order of most unique relationsfirst and with clever multifold coverage may often be able to locaterecords (at least at the block level where the rest may be sortedalgorithmically) using 1-2 tables/index calls.

There is little distinction left between hardware and softwareimplementations of aspects of systems; the use of hardware or softwareis generally (but not always, in that in certain contexts the choicebetween hardware and software may become significant) a design choicerepresenting cost vs. efficiency tradeoffs. There are various vehiclesby which processes and/or systems and/or other technologies describedherein may be effected (e.g., hardware, software, and/or firmware), andthat the preferred vehicle will vary with the context in which theprocesses and/or systems and/or other technologies are deployed. Forexample, if an implementer determines that speed and accuracy areparamount, the implementer may opt for a mainly hardware and/or firmwarevehicle; if flexibility is paramount, the implementer may opt for amainly software implementation; or, yet again alternatively, theimplementer may opt for some combination of hardware, software, and/orfirmware.

The foregoing detailed description has set forth various embodiments ofthe devices and/or processes via the use of block diagrams, flowcharts,and/or examples. Insofar as such block diagrams, flowcharts, and/orexamples contain one or more functions and/or operations, it will beunderstood by those within the art that each function and/or operationwithin such block diagrams, flowcharts, or examples may be implemented,individually and/or collectively, by a wide range of hardware, software,firmware, or virtually any combination thereof. In one embodiment,several portions of the subject matter described herein may beimplemented via Application Specific Integrated Circuits (ASICs), FieldProgrammable Gate Arrays (FPGAs), digital signal processors (DSPs), orother integrated formats. However, those skilled in the art willrecognize that some aspects of the embodiments disclosed herein, inwhole or in part, may be equivalently implemented in integratedcircuits, as one or more computer programs running on one or morecomputers (e.g., as one or more programs running on one or more computersystems), as one or more programs running on one or more processors(e.g., as one or more programs running on one or more microprocessors),as firmware, or as virtually any combination thereof, and that designingthe circuitry and/or writing the code for the software and or firmwarewould be well within the skill of one of skill in the art in light ofthis disclosure. In addition, those skilled in the art will appreciatethat the mechanisms of the subject matter described herein are capableof being distributed as a program product in a variety of forms, andthat an illustrative embodiment of the subject matter described hereinapplies regardless of the particular type of signal bearing medium usedto actually carry out the distribution. Examples of a signal bearingmedium include, but are not limited to, the following: a recordable typemedium such as a floppy disk, a hard disk drive, a Compact Disc (CD), aDigital Video Disk (DVD), a digital tape, a computer memory, etc.; and atransmission type medium such as a digital and/or an analogcommunication medium (e.g., a fiber optic cable, a waveguide, a wiredcommunications link, a wireless communication link, etc.).

Those skilled in the art will recognize that it is common within the artto describe devices and/or processes in the fashion set forth herein,and thereafter use engineering practices to integrate such describeddevices and/or processes into data processing systems. That is, at leasta portion of the devices and/or processes described herein may beintegrated into a data processing system via a reasonable amount ofexperimentation. Those having skill in the art will recognize that atypical data processing system generally includes one or more of asystem unit housing, a video display device, a memory such as volatileand non-volatile memory, processors such as microprocessors and digitalsignal processors, computational entities such as operating systems,drivers, graphical user interfaces, and applications programs, one ormore interaction devices, such as a touch pad or screen, and/or controlsystems including feedback loops and control motors (e.g., feedback forsensing position and/or velocity; control motors for moving and/oradjusting components and/or quantities). A typical data processingsystem may be implemented utilizing any suitable commercially availablecomponents, such as those typically found in datacomputing/communication and/or network computing/communication systems.The herein described subject matter sometimes illustrates differentcomponents contained within, or connected with, different othercomponents. It is to be understood that such depicted architectures aremerely examples and that in fact many other architectures may beimplemented which achieve the same functionality. In a conceptual sense,any arrangement of components to achieve the same functionality iseffectively “associated” such that the desired functionality isachieved. Hence, any two components herein combined to achieve aparticular functionality may be seen as “associated with” each othersuch that the desired functionality is achieved, irrespective ofarchitectures or intermediate components. Likewise, any two componentsso associated may also be viewed as being “operably connected”, or“operably coupled”, to each other to achieve the desired functionality,and any two components capable of being so associated may also be viewedas being “operably couplable”, to each other to achieve the desiredfunctionality. Specific examples of operably couplable include but arenot limited to physically connectable and/or physically interactingcomponents and/or wirelessly inter-actable and/or wirelessly interactingcomponents and/or logically interacting and/or logically inter-actablecomponents.

With respect to the use of substantially any plural and/or singularterms herein, those having skill in the art may translate from theplural to the singular and/or from the singular to the plural as isappropriate to the context and/or application. The varioussingular/plural permutations may be expressly set forth herein for sakeof clarity.

It will be understood by those within the art that, in general, termsused herein, and especially in the appended claims (e.g., bodies of theappended claims) are generally intended as “open” terms (e.g., the term“including” should be interpreted as “including but not limited to,” theterm “having” should be interpreted as “having at least,” the term“includes” should be interpreted as “includes but is not limited to,”etc.). It will be further understood by those within the art that if aspecific number of an introduced claim recitation is intended, such anintent will be explicitly recited in the claim, and in the absence ofsuch recitation no such intent is present. For example, as an aid tounderstanding, the following appended claims may contain usage of theintroductory phrases “at least one” and “one or more” to introduce claimrecitations. However, the use of such phrases should not be construed toimply that the introduction of a claim recitation by the indefinitearticles “a” or “an” limits any particular claim containing suchintroduced claim recitation to inventions containing only one suchrecitation, even when the same claim includes the introductory phrases“one or more” or “at least one” and indefinite articles such as “a” or“an” (e.g., “a” and/or “an” should typically be interpreted to mean “atleast one” or “one or more”); the same holds true for the use ofdefinite articles used to introduce claim recitations. In addition, evenif a specific number of an introduced claim recitation is explicitlyrecited, those skilled in the art will recognize that such recitationshould typically be interpreted to mean at least the recited number(e.g., the bare recitation of “two recitations,” without othermodifiers, typically means at least two recitations, or two or morerecitations). Furthermore, in those instances where a conventionanalogous to “at least one of A, B, and C, etc.” is used, in generalsuch a construction is intended in the sense one having skill in the artwould understand the convention (e.g., “a system having at least one ofA, B, and C” would include but not be limited to systems that have Aalone, B alone, C alone, A and B together, A and C together, B and Ctogether, and/or A, B, and C together, etc.). In those instances where aconvention analogous to “at least one of A, B, or C, etc.” is used, ingeneral such a construction is intended in the sense one having skill inthe art would understand the convention (e.g., “a system having at leastone of A, B, or C” would include but not be limited to systems that haveA alone, B alone, C alone, A and B together, A and C together, B and Ctogether, and/or A, B, and C together, etc.). It will be furtherunderstood by those within the art that virtually any disjunctive wordand/or phrase presenting two or more alternative terms, whether in thedescription, claims, or drawings, should be understood to contemplatethe possibilities of including one of the terms, either of the terms, orboth terms. For example, the phrase “A or B” will be understood toinclude the possibilities of “A” or “B” or “A and B.”

While certain example techniques have been described and shown hereinusing various methods, devices and systems, it should be understood bythose skilled in the art that various other modifications may be made,and equivalents may be substituted, without departing from claimedsubject matter. Additionally, many modifications may be made to adapt aparticular situation to the teachings of claimed subject matter withoutdeparting from the central concept described herein. Therefore, it isintended that claimed subject matter not be limited to the particularexamples disclosed, but that such claimed subject matter also mayinclude all implementations falling within the scope of the appendedclaims, and equivalents thereof.

The invention claimed is:
 1. A method comprising: receiving a databaseby a cloud digital service provider; subsequent to receiving thedatabase, initially storing a basic database index by the cloud digitalservice provider, wherein the basic database index is initially storedin a first memory associated with a first performance level, wherein thebasic database index is configured to locate data records in thedatabase, and wherein the basic database index comprises key values tolocate the data records in the database; building an optimized databaseindex configured to locate data records in the database, wherein theoptimized database index comprises key values to locate the data recordsin the database; storing the optimized database index in a second memoryassociated with a second performance level, wherein the secondperformance level is lower speed than the first performance level, andwherein the first performance level is higher speed than the secondperformance level; gradually shifting, during the building of theoptimized database index, from use of the basic database index in thefirst memory to locate data records in the database, to use of theoptimized database index in the second memory to locate data records inthe database, to thereby transition from index coverage for the databasebeing dominated by the basic database index in the first memory to indexcoverage for the database being dominated by the optimized databaseindex in the second memory; wherein building the optimized databaseindex comprises: receiving queries comprising requests for one or moreof the data records in the database and modifying the basic databaseindex using query data corresponding to received queries to configurethe optimized database index to provide faster responses to receivedqueries.
 2. The method of claim 1, wherein the optimized database indexis configured to locate data records with fewer table lookups or inshorter times than the basic database index.
 3. The method of claim 2,wherein the optimized database index is configured to locate datarecords with 5 or fewer table lookups.
 4. The method of claim 2, whereinthe optimized database index is configured to locate data records in atime of 50 milliseconds or shorter.
 5. The method of claim 1, furthercomprising: measuring a time or number of table lookups involved inretrieving a requested data record using a portion of the basic databaseindex; comparing the time or number of table lookups to a performancerequirement; and moving the portion of the basic database index to theoptimized database index when the time or number of table lookups meetsthe performance requirement.
 6. The method of claim 1, wherein thedatabase as received by the cloud digital service provider comprises thedata records without accompanying query history data from a prior clouddigital service provider.
 7. The method of claim 1, further comprisingdiscontinuing the basic database index in the first memory, andsubsequently retrieving requested data records using the optimizeddatabase index in the second memory, to thereby discontinue use of thefirst memory in connection with responding to queries for data recordsin the database.
 8. The method of claim 1, wherein the first memorycomprises a cache-type memory.
 9. The method of claim 1, wherein thesecond memory comprises a disk-type memory.
 10. The method of claim 1,wherein a response time to retrieve requested data records in responseto received queries is maintained approximately constant while graduallyshifting from use of the basic database index to use of the optimizeddatabase index.
 11. The method of claim 1, wherein the modifying thebasic database index using query data corresponding to received queriesto configure the optimized database index to provide faster responses toreceived queries is performed by a database index optimization tool. 12.A non-transitory computer readable storage medium having computerexecutable instructions executable by a processor, the instructionsthat, when executed by the processor, cause the processor to: receive adatabase by a cloud digital service provider; subsequent to the databasebeing received, initially store a basic database index by the clouddigital service provider, wherein the basic database index is stored ina first memory associated with a first performance level, wherein thebasic database index is configured to locate data records in thedatabase, and wherein the basic database index comprises key values tolocate the data records in the database; build an optimized databaseindex configured to locate data records in the database, wherein theoptimized database index comprises key values to locate the data recordsin the database; store the optimized database index in a second memoryassociated with a second performance level, wherein the secondperformance level is lower speed than the first performance level, andwherein the first performance level is higher speed than the secondperformance level; gradually shift, during the building of the optimizeddatabase index, from use of the basic database index in the first memoryto locate data records in the database, to use of the optimized databaseindex in the second memory to locate data records in the database, tothereby transition from index coverage for the database being dominatedby the basic database index in the first memory to index coverage forthe database being dominated by the optimized database index in thesecond memory; wherein the instructions that cause the processor tobuild the optimized database index comprise instructions that cause theprocessor to: receive queries comprising requests for one or more of thedata records in the database and modify the basic database index usingquery data corresponding to received queries to configure the optimizeddatabase index to provide faster responses to received queries.
 13. Aserver computer comprising: a processor; a memory; and a databaseperformance balancing tool stored in the memory and executable by theprocessor, wherein the database performance balancing tool is configuredto: receive a database by a cloud digital service provider; subsequentto the database being received, initially store a basic database indexby the cloud digital service provider, wherein the basic database indexis stored in a first memory associated with a first performance level,wherein the basic database index is configured to locate data records inthe database, and wherein the basic database index comprises key valuesto locate the data records in the database; build an optimized databaseindex configured to locate data records in the database, wherein theoptimized database index comprises key values to locate the data recordsin the database; store the optimized database index in a second memoryassociated with a second performance level, wherein the secondperformance level is lower speed than the first performance level, andwherein the first performance level is higher speed than the secondperformance level; gradually shift, during the building of the optimizeddatabase index, from use of the basic database index in the first memoryto locate data records in the database, to use of the optimized databaseindex in the second memory to locate data records in the database, tothereby transition from index coverage for the database being dominatedby the basic database index in the first memory to index coverage forthe database being dominated by the optimized database index in thesecond memory; wherein the database performance balancing tool isconfigured to receive queries comprising requests for one or more of thedata records in the database and modify the basic database index usingquery data corresponding to received queries to configure the optimizeddatabase index to provide faster responses to received queries.
 14. Theserver computer of claim 13, wherein the optimized database index isconfigured to locate data records with fewer table lookups or in shortertimes than the basic database index.
 15. The server computer of claim13, wherein the database performance balancing tool is configured to:measure a time or number of table lookups involved in retrieving arequested data record using a portion of the basic database index;compare the time or number of table lookups to a performancerequirement; and move the portion of the basic database index to theoptimized database index when the time or number of table lookups meetsthe performance requirement.
 16. The server computer of claim 13,wherein the database as received by the cloud digital service providercomprises the data records without accompanying query history data froma prior cloud digital service provider.
 17. The server computer of claim13, wherein the database performance balancing tool is configured todiscontinue the basic database index in the first memory, andsubsequently retrieve requested data records using the optimizeddatabase index in the second memory, to thereby discontinue use of thefirst memory in connection with responding to queries for data recordsin the database.
 18. The server computer of claim 13, wherein the firstmemory comprises a cache-type memory and wherein the second memorycomprises a disk-type memory.